home *** CD-ROM | disk | FTP | other *** search
/ Amiga Developer CD 2.1 / Amiga Developer CD v2.1.iso / Reference / Amiga_Mail_Vol2 / Archives / Plain / jf93 / ASCII / MemPools / MemPools.txt < prev    next >
Encoding:
Text File  |  1993-03-01  |  8.4 KB  |  212 lines
  1. (c) Copyright 1993 Commodore-Amiga, Inc.   All rights reserved.
  2. The information contained herein is subject to change without notice,
  3. and is provided "as is" without warranty of any kind, either expressed
  4. or implied.  The entire risk as to the use of this information is
  5. assumed by the user.
  6.  
  7.  
  8. Memory Pools
  9.  
  10.  
  11. by Mark Ricci
  12.  
  13.  
  14.  
  15. A memory pool is a block of memory that an application allocates for
  16. all its memory needs.  The application draws from this pool rather
  17. than the system's free memory list whenever it requires memory.
  18.  
  19. Memory pools add to the efficiency of the system and applications in
  20. two ways.  The first is a potential decrease in memory fragmentation.
  21. Memory fragmentation is a condition where system memory is made up of
  22. blocks of allocated memory interspersed with blocks of free memory.
  23. The second benefit of memory pools is faster memory allocations and
  24. deallocations.
  25.  
  26. System memory starts out as one large, contiguous block.  The first
  27. time a task allocates memory, the system memory is broken into two
  28. blocks--allocated memory and free memory.  As different tasks
  29. allocate memory, the allocated memory block increases and the free
  30. memory block decreases as shown in Figure 1. The memory blocks remain
  31. contiguous until a task frees some memory.  At that point, a gap may
  32. appear in the block of allocated memory if the newly freed block was
  33. not the last one allocated.  While this creates additional free
  34. memory, it also means that free memory is now two or more
  35. non-contiguous fragments instead of one contiguous block.  In a
  36. multitasking system like the Amiga, tasks are constantly allocating
  37. and freeing memory which can create many gaps in memory.  As a
  38. result, free memory can consist of many small pieces rather than one
  39. large block (Figure 2).
  40.  
  41.  
  42.  
  43. This can lead to problems if an application needs a large block of
  44. contiguous memory.  For example, consider an application that needs a
  45. block of memory 200,000 bytes long.  If free memory is severely
  46. fragmented, the largest block of free memory may only be 150k.  The
  47. system may have five megabytes of free memory available, but that
  48. five megabytes of memory is broken into fragments no larger than
  49. 150k.  In this case, the application cannot allocate its 200k.
  50.  
  51. By having an application take a pool of memory and allocate from it,
  52. fragmentation of system memory is decreased.  An application may
  53. require six allocations ranging from 20 to 678 bytes in size which
  54. can be scattered throughout system memory.  However, if those same
  55. six allocations are taken from a pool, the fragmentation occurs
  56. within the pool, but as far as the system is concerned, it's missing
  57. one large block instead of six small ones.
  58.  
  59. An application using a memory pool will have faster memory
  60. allocations because the memory list of a pool is smaller, and
  61. therefore easier to traverse than the memory list of the system
  62. memory.  For deallocations, it's even faster because deleting the
  63. pool itself deletes all the individual allocations made from it
  64. instead of having to deallocate each piece that was allocated.
  65.  
  66.  
  67. Memory Pool Organization
  68.  
  69. A memory pool consists of units called puddles.  Other than that, it
  70. has no formal organization.  There is no pool structure defined
  71. anywhere.  All you know about a pool is its address.  Exec's pool
  72. manager handles the rest of the details.
  73.  
  74. When you create a pool, you specify the size of its puddles and a
  75. threshold value, not the size of the pool.  This is because memory
  76. pools are dynamic, they have no fixed size.  The pool manager takes
  77. the memory for your application from the puddles.  As you require
  78. memory, the pool manager expands the pool by adding puddles, and as
  79. you free memory, the pool manager shrinks the pool by deleting
  80. puddles.
  81.  
  82. The size of the puddles is important because the pool manager will
  83. try to use as much of a puddle as possible before adding a new
  84. puddle.  Each time you allocate memory from the pool, the pool
  85. manager takes the memory from a puddle unless an allocation exceeds
  86. the amount of memory remaining in a puddle.  If the allocation
  87. request exceeds the memory remaining in a puddle, the pool manager
  88. adds a new puddle.  If the allocation exceeds the pool's puddle size,
  89. the pool manager will create a special oversized puddle to
  90. accommodate the application.
  91.  
  92. The key is to use all the drops in a puddle.  If you create a pool
  93. with puddles of 200 bytes and allocate 150 bytes at a time, you'll
  94. waste 50 bytes in every puddle.  Set the puddle size in accordance
  95. with your memory requirements.
  96.  
  97. The threshold value is the size of the largest allocation to use
  98. within a single puddle.  An allocation request larger than the
  99. threshold value causes the pool manager to add a new puddle.
  100. Ideally, the threshold value should be the size of the largest
  101. allocation you will make.
  102.  
  103. The relationship between puddle size and threshold can be tuned for
  104. optimal utilization of a pool.   Threshold sizes cannot exceed puddle
  105. sizes and are recommended to be one half the puddle size so that you
  106. can fit two of your largest allocations in a single puddle.  However,
  107. if you are going to have a mix of large and small allocations, you
  108. might want to set a threshold value that allocates a majority of a
  109. puddle for a large allocation, and then uses up the remainder of the
  110. puddle with the smaller allocations.
  111.  
  112.  
  113.  
  114. Creating a Memory Pool
  115.  
  116. You create a memory pool by calling CreatePool() specifying the
  117. puddle size, threshold size, and memory type.  The memory type is
  118. borrowed from the AllocMem() function and is comprised of the MEMF_
  119. flags defined in <exec/memory.h>.  See the Autodoc for AllocMem() for
  120. more information on those flags.
  121.  
  122.  
  123. If successful, CreatePool() returns the address of the memory pool.
  124.  
  125.     APTR mem_pool;
  126.  
  127.     if (mem_pool = CreatePool(MEMF_FAST,4096,2048))
  128.     {
  129.         .  .  .
  130.     }
  131.  
  132.     else
  133.         printf("Pool could not be created.\n");
  134.  
  135.  
  136. The example above attempts to create a pool of Fast memory with a
  137. puddle size of 4096 bytes and a threshold size of 2048 bytes.
  138.  
  139. If your application requires memory of different types (for example,
  140. Chip memory and Fast memory), it must create a pool for each type.
  141.  
  142. Take note, again, that all you know about a pool is its address.  Do
  143. not poke around it trying to figure out its organization.  It's
  144. private for a reason!
  145.  
  146.  
  147. Allocating Memory from a Pool's Puddles
  148.  
  149. Memory is obtained from a pool's puddles by calling AllocPooled().
  150. AllocPooled() requires a pointer to the memory pool and the size of
  151. the memory block needed.  If successful, AllocPooled() returns a
  152. pointer to the memory.
  153.  
  154.     struct timerequest *TimerReq;
  155.  
  156.     if (TimerReq = AllocPooled(mem_pool, sizeof(struct timerequest))
  157.     {
  158.         .  .  .
  159.     }
  160.  
  161.     else
  162.         printf("Memory could not be allocated.\n");
  163.  
  164.  
  165. Freeing Memory from a Pool's Puddles
  166.  
  167. An application can free a block of memory it allocated from a pool by
  168. calling FreePooled():
  169.  
  170.     FreePooled(mem_pool, mem_drop, mem_size);
  171.  
  172. This function requires a pointer to the memory pool (mem_pool), a
  173. pointer to the block of memory being freed (mem_drop), and the size
  174. of the memory being freed (mem_size).
  175.  
  176.  
  177. Deleting a Memory Pool
  178.  
  179. A memory pool is deleted by calling DeletePool() with a pointer to
  180. the memory pool you wish to delete.
  181.  
  182.     DeletePool(mem_pool);
  183.  
  184. Deleting a pool also frees the puddles in it.  This is quicker than
  185. doing individual FreePooled() calls.  For example, a text editor will
  186. allocate memory for each line of the file being edited.  When the
  187. editor is exited, each of the allocations has to be freed.  With
  188. DeletePool(), it would take only one call instead of many.
  189.  
  190.  
  191. Why Use Pools When You Can Allocate Memory Yourself?
  192.  
  193. You could simulate memory pools yourself by allocating the memory you
  194. think you'll need and then using it as you go along.  You'll also
  195. have to keep track of your usage and if you exceed your allocation,
  196. you will have to allocate additional memory.  Another potential
  197. problem is that unlike pools where you dynamically get memory, the
  198. allocation scheme requires you to attempt one large allocation, which
  199. may fail, and then requires at least two smaller allocations.  At
  200. that point, you're no farther ahead than you were before.
  201.  
  202. With pools, you have the pool manager to handle all the details of
  203. allocating memory.  You can sit back and create the pool, allocate
  204. memory from the puddles and free the pool when you're done.  That's a
  205. lot easier than doing it yourself.
  206.  
  207. Here's an additional incentive for using memory pools:
  208.  
  209. Future memory technologies will be implemented through pools.
  210.  
  211. The example below illustrates the use of memory pools instead of
  212. allocating system memory.